ETO Development Tools 1/ETO Development Tools 1.iso/Essentials/MacApp Documentation/MacApp AppleLink Messages/MacApp.Tech$ 4⁄20⁄90/1120-Scalable Views revis-Apr90

Text File | 1990-04-16 | 5.1 KB | 116 lines | [TEXT/GEOL]

Item    9515161                         16-April-90        17:54DST

From:   UK0392                          EHN & DIJ Oakley,IDV

To:     POWERUP.ENG                     Power Up Software,PRT

cc:     MACAPP.TECH$                    MacApp Technical

Sub:    Scalable Views revisited

James,
I have now had a chance to study your exemplary Scalable Views class, as
promised.  Whilst it is an impressive piece of work - far more clever than I
would ever achieve - I think that it has some fundamental flaws in its
approach, some of which we have already discussed.

I think that the ability for the programmer to control exactly what is scaled,
and how, is crucial in all applications which would use scalable views.  Aside
from specialist CAD/CAM areas, suppose that I have an image in a view, which
has a content which is a representation of what I am producing, and various
labels etc.  If I scale it with Scalable Views, then I presume that everything
will be changed, so that my labels etc. would become either huge or tiny.
Similarly, spatial relationships may not have to be scaled so simply - a one
pixel gap may have to be maintained however small the view becomes, in order to
retain clarity & meaning.

The programmer also requires control over whether the document when printed is
scaled or not - I cited the instance of our users, who want (in fact HAVE) to
be able to print at the current scaling, in contrast with the example of
a DTP program, where no matter what the current visible scale, the printed
output must be at full scale (although thumbnails might be a useful extension
of my proposals?).

I note that your scaling factor must be an integer.  I regret that integral
values are often insufficient for drawing programs, in that the almost
infinitely variable powers afforded by reals are needed - this becomes more
critical, of course, once we are talking of magnification of the view, rather
than reduction.

I am also concerned that Scalable Views is very unlikely ever to be a part of
MacApp, as it imposes not inconsiderable code & data overhead (polygon and
region stuff, for example) and yet another set of coordinate conversions.
Logically, then, scalable views would be another class of view, which I think
makes life less elegant and more complex.  Contrast instead the lean and simple
(for I am of simple mind) approach which I would beg to submit for your
consideration:

CONST {add}
   cZoomIn4=   304; {magnify by factor of 4}
   cZoomIn2=   305; {magnify by factor of 2}
   cZoomOut2   =   306; {reduce by factor of 2}
   cZoomOut4   =   307; {reduce by factor of 4}
   cZoomFit=   308; {scale to fit in window}
   cNormSize   =   309; {default size}
   {could also have set to particular scale, of course, or fixed
   percentages e.g. DTP applications}

TYPE
{to} TDocument = OBJECT (TEvtHandler)
{add field}
   fZoomPower: REAL; {current zoom power}
   {1.0 -> 1:1 ratio on screen, with 1 pixel = 1 unit,
   whilst (e.g.) 100.0 -> 1:100 ratio, with 1 pixel
   = 100 units.  It is implementation dependent as
   to what limits you place on this; numbers between
   0 and 1 are magnifications, e.g. 0.5 is 2:1 ratio}
   END;

{to} TView = OBJECT (TEvtHandler)
{alter to}
   PROCEDURE TView.Draw(area: Rect; aZoomPower: REAL);
   END;

{then for each drawable object, you require a method:}
   PROCEDURE TMyObject.Draw(theZoom: REAL);
   {it is the responsibility of the programmer to implement scaling of
   the drawing, if required}

{and one new command}
   TZoomCommand= OBJECT (TCommand)
   fOldZoom:   REAL;
   fNewZoom:   REAL;
    {Initialization}
   PROCEDURE TZoomCommand.IZoomCommand(aCmdNumber: CmdNumber;
   myDocument: TDocument; itsView: TView; itsScroller: TScroller;
   oldZoom: REAL); {initialise & calculate fNewZoom from aCmdNumber}
    {Command performing}
   PROCEDURE TZoomCommand.DoIt; OVERRIDE; {call view to redraw to fNewZoom}
   PROCEDURE TZoomCommand.UndoIt; OVERRIDE; {call view to redraw to fOldZoom}
   PROCEDURE TZoomCommand.RedoIt; OVERRIDE; {call view to redraw to fNewZoom}
    {Utility routine}
   PROCEDURE TZoomCommand.DoZoom(oldZoom, newZoom: REAL); {actually call it}
    {Mouse Tracking}
    {if you wish to, you can implement marqueed zoom areas, or the 'click
    and zoom' magnifying glass of many drawing apps, with methods here.  The
    only complication, of course, is retaining your place in the view!}
    {Debugging}
   PROCEDURE TZoomCommand.Fields (PROCEDURE DoToField (fieldName: Str255;
     fieldAddr: Ptr;
     fieldType: INTEGER)); OVERRIDE;
   END;

all of which are almost trivial to implement.  If an application does **not**
require scaling/zooming, then the overhead is nil.  If it does, then it is
all plane sailing to implement, and there is hardly any unwanted overhead.  As
regards my applications, whilst your Scalable Views would be of no use to them,
the above (which is not, incidentally, how I have implemented it yet!) would
definitely be a great improvement to MacApp.

If there is interest, I would be happy to flesh out the above in the Class
Room, so folk can compare and contrast the two approaches to scaling views, and
we can also take on board the requirements of others.

Regards, Howard.